home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1995 April / Internet Tools.iso / dos_win / winsock / wsock20 / ws2tcpex.txt < prev    next >
Encoding:
Text File  |  1995-01-31  |  10.3 KB  |  390 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Windows Sockets 2
  8. TCP/IP Extensions
  9.  
  10.  
  11.  
  12. Jan 31, 1995
  13.  
  14.  
  15.  
  16.  
  17. Draft
  18.  
  19.  
  20. INTRODUCTION
  21.  
  22.  
  23.     This document describes the requirement of the TCP/IP 
  24. Extension Group and lists proposed updates to the WinSock2  
  25. API and SPI. 
  26.  
  27.  
  28. SUMMARY OF PROPOSED FEATURES
  29.  
  30.  Interfaces list support  ability to get list of supported 
  31. interfaces and some characteristics for each interface.
  32.  
  33.  Support for IP_TTL option
  34.  
  35.  RFC 793/1122 OOB - allow to choose the type of OOB support.
  36.  
  37.  multicast support -  ability to send and receive multicast 
  38. packets.
  39.  
  40.  IP6 addresses support - ability to choose the type of IP 
  41. address to use.
  42.  
  43.  Disable UDP checksum - ability to turn of UDP checksum.
  44.  
  45.  IP options - abilty to specify IP options. 
  46.  
  47.  RAW_ICMP/RAW_IP - support for two types of raw data: with 
  48. and without  IP header.
  49.  
  50.  
  51. NEW FEATURES DESCRIPTION AND JUSTIFICATION
  52.  
  53.  
  54. Interfaces list support  - ability to get list of supported 
  55.              interfaces and some characteristics for each 
  56.             interface.
  57.  
  58.             The list of supported interfaces should include at 
  59.             least the following parameters for each interface:
  60.  
  61.          Interface ID (opaque value);
  62.          Flags (Up/Down, Multicast, Broadcast, etc.);
  63.          IP address;
  64.          subnet mask;
  65.          broadcast address;
  66.  
  67.          Inspite of the fact that this requirement contradicts 
  68.          the 'General Referential Parameter' ("Windows Sockets 
  69.          is not SNMP'), it was decided to include interface list 
  70.          support into this draft. The Reasons for this are:
  71.          
  72.             there were multiple requests for support of  
  73.             'gethostid','get my IP address', etc.
  74.  
  75.             multicast support for a host with multiple 
  76.             interfaces requires to know the list of these 
  77.             interfaces.
  78.  
  79. RFC 793/1122 OOB  - allow to choose the type of OOB support.
  80.  
  81.             Support a socket option which allows to set the 
  82.             desired type of OOB data handling.
  83.  
  84.  
  85. Multicast support  - ability to send and receive multicast 
  86.             packets.
  87.  
  88.         Multicast support should allow:
  89.  
  90.          send/receive multicast packets;
  91.          join/leave multicast groups;
  92.          set TTL for multicast packets; 
  93.          choose interface which will be used by a socket 
  94.          when sending multicast packets.
  95.  
  96.          'IP Multicast extensions for 4.3 BSD' by Steve Deering 
  97.          should be used as a guideline for implementation.
  98.  
  99.  
  100. IP6 addresses support - ability to choose the type of IP 
  101.             address to use.
  102.  
  103.         It should be possible to specify both the IPv4 and 
  104.         IPv6 type of IP addresses.
  105.  
  106.         IPv6 addresses are treated as addresses of different 
  107.         family, i.e. IPv4 addresses belong to AF_INET adress 
  108.         family, while IPv6 addresses belong to AF_INET6 family. 
  109.         The new structure should be defined to describe IPv6 
  110.         addresses:
  111.  
  112.     struct sockaddr_in6{
  113.         u_short        sin6_family;    // AF_INET6
  114.         u_short        sin6_port;    // port number
  115.         u_long        sin6_flowlabel;    // IPv6 flowlabel
  116.         u_long        sin6_addr[4];    // IPv6 address
  117.     };
  118.  
  119. Disable UDP checksum  - ability to turn of UDP checksum.
  120.  
  121.     Setting  'UDP checksum off'  causes  UDP datagrams 
  122.     to be sent with a checksum of zero, and  received 
  123.     UDP datagrams with a checksum of zero to be passed 
  124.     to the application.  The default is 'UDP checksum 
  125.     on'. In this case the real checksum is calculated 
  126.     for the UDP datagrams to be sent, and UDP 
  127.     datagrams with checksum of zero are silently 
  128.     discarded.(See RFC 1122,section 4.1.3.4)
  129.  
  130. IP options -     abilty to specify IP options 
  131.  
  132.     IP security requires the access to the IP option 
  133.     part of the IP header. The format of the passed 
  134.     options should follow the BSD imlementation. 
  135.  
  136.  
  137. Support IP_TTL option -    Ability to overwrite the default 
  138.             value of TTL in IP header.
  139.  
  140. RAW_ICMP/RAW_IP  - support for two types of raw data: with and 
  141.         without  IP header.
  142.  
  143.         A user should be able to specify two types of 
  144.         'raw' sockets. One type assumes that an IP header 
  145.         is created  by the WinSock2 (or by the stack) for 
  146.         packets sent over  the socket. Another type 
  147.         assumes that  user must   provide an IP header for 
  148.         each packet sent.
  149.  
  150.  
  151.  
  152.  
  153. PROPOSED UPDATES TO WINSOCK2 API/SPI
  154.  
  155.  
  156.     These updates introduce several new options. Some of 
  157. them are optional. If Service Provider doesnÆt support them, 
  158. it should return WSAEINVAL on an attempt to get/set one of 
  159. these options. If an application wants to know if any of 
  160. these options is supported, it may open a socket and call 
  161. 'getsockopt()' for the choosen option.
  162.  
  163.  INTERFACES LIST SUPPORT
  164.  
  165.     New command SIOGIFCONF should be added to the 'ioctl'
  166. function. This command returns the list of configured 
  167. intefaces and their parameters.  The support of this command 
  168. is required for WinSock2
  169. compliant service providers. Both API and SPI  description 
  170. of the 'ioctl' function should be updated.  
  171.  
  172.     The parameter argp points to the buffer which contains 
  173. the information about interfaces. The description of the 
  174. structure of this buffer follows:
  175.  
  176. Definition INTERFACE_LIST Structure:
  177.  
  178. DWORD ilLengthOfList - on input, the count of bytes in 
  179. the buffer pointed by argp; on output, 
  180. the count of bytes written into this 
  181. buffer.
  182.  
  183. INTERFACE_INFO ilInterface[1] - array of structures 
  184. each of which describes a single 
  185. interface.
  186.  
  187. Definition INTERFACE_INFO Structure:
  188.  
  189. DWORD iiFlags - a bitmask describing the status of the 
  190. interface. The following flags are 
  191. possible:
  192.  
  193.     IFF_UP            - interface is up
  194.     IFF_BROADCAST    - broadcast is supported
  195.     IFF_LOOPBACK    - this is loopback interface
  196.     IFF_POINTTOPOINT    - this is point-to-point link
  197.     IFF_MULTICAST    - multicat is supported
  198.  
  199. sockaddr FAR *iiAddress - address of the interface
  200.  
  201. sockaddr FAR *iiBroadcastAddress - broadcast address of 
  202. the interface or the address of 
  203. the other side for point-to-point 
  204. links
  205.  
  206. sockaddr FAR *iiNetmask - netmask used by the interface
  207.  
  208.  
  209.  
  210.  NEW IP OPTIONS
  211.  
  212.     The set of additional IP option requires the updates in 
  213. the description of 'get/setsockopt'  both in WinSock2 API 
  214. and SPI documents. These update includes the new supported 
  215. level IPPROTO_IP and the following new options:
  216.  
  217.         IP_OPTIONS         - optional
  218.         IP_TOS            - optional
  219.         IP_TTL            - optional
  220.         IP_HDRINCL        - required  for  SOCK_RAW  
  221.                         socket types.
  222.  
  223.         The following options are required if  protocol 
  224. supports multicast , i.e. flag XP1_SUPPORTS_MULTICAST is set 
  225. on output in WSAEnumProtocols():
  226.  
  227.         IP_MULTICAST_IF    
  228.         IP_MULTICAST_TTL    
  229.         IP_MULTICAST_LOOP
  230.         IP_ADD_MEMBERSHIP
  231.         IP_DROP_MEMBERSHIP    
  232.  
  233. Value            Type            Meaning
  234.             
  235. IP_OPTIONS        char FAR *    List of IP options to be 
  236.                     inserted into outcoming 
  237.                     packets. Setting the new 
  238.                     options overwrites all the 
  239.                     previously specified 
  240.                     options. Setting optval to 
  241.                     zero means removing of all 
  242.                     the previously specified 
  243.                     options.
  244.  
  245. IP_TOS            int        Specifies type of service to 
  246.                     be used
  247.  
  248. IP_TTL            int        Specify TTL to be used
  249.  
  250. IP_HDRINCL        BOOL        If true, user should include 
  251.                     IP header in the packets 
  252.                     sent over SOCK_RAW 
  253.                     interface, otherwise the 
  254.                     header is provided by  the 
  255.                     protocol stack (service 
  256.                     provider).
  257.  
  258. IP_MULTICAST_IF    struct in_addr FAR *    Select interface for 
  259.                     outgoing multicast packets. 
  260.                     The optval should point to 
  261.                     the address of the interface 
  262.                     to be used. If NULL, the 
  263.                     default interface is used.
  264.  
  265. IP_MULTICAST_TTL    int        TTL used for the multicast 
  266.                     packets
  267.  
  268. IP_MULTICAST_LOOP    BOOL        If true, multicast loopback 
  269.                     is enabled, otherwise - 
  270.                     disabled.
  271.  
  272. IP_ADD_MEMBERSHIP   struct ip_mreq FAR *    Specify the multicast group 
  273.                         to join
  274.  
  275. IP_DROP_MEMBERSHIP  struct ip_mreq FAR *    Specify the multicast group 
  276.                         to leave
  277.  
  278.  
  279.  
  280. struct ip_mreq  {
  281.     struct in_addr imr_multiaddr; /* multicust group to 
  282. join/drop */
  283.     struct in_addr imr_interface; /* interface to join/drop 
  284. on */
  285.  
  286.  
  287.  RFC 793/1122 OOB
  288.  
  289.     New socket option requires the updates in the 
  290. description of 'get/setsockopt'  both in WinSock2 API and 
  291. SPI documents. This option allows to choose between BSD and 
  292. RFC-1122 style of expedited data. This option is not 
  293. required.
  294.  
  295. Level        Value            Type        Meaning
  296.  
  297. SOL_SOCKET    SO_EXPEDITED_1122    BOOL    If set, the Service 
  298.                         Provider implements the 
  299.                         expedited data as 
  300.                         specified in RFC-1222, 
  301.                         otherwise  the BSD stily 
  302.                         is used. This option can 
  303.                         be set on the connection 
  304.                         only once, i.e. once on, 
  305.                         this option can not be 
  306.                         turned off.
  307.  
  308.  
  309.  
  310.  DISABLE UDP CHECKSUM
  311.  
  312.     The new UDP option requires the updates in the 
  313. description of 'get/setsockopt'  both in WinSock2 API and 
  314. SPI documents.
  315.  
  316. Level        Value        Type        Meaning
  317.  
  318. IPPROTO_UDP    UDP_NOCHECKSUM    BOOL    If the option is set,  
  319.                     UDP datagrams are sent 
  320.                     with the checksum of 
  321.                     zero and  received UDP 
  322.                     datagrams with checksum 
  323.                     of zero are passed to 
  324.                     application. This option 
  325.                     is required. If a 
  326.                     service provider does 
  327.                     not have a mechanism to 
  328.                     disable UDP checksum 
  329.                     calculation, it may just 
  330.                     store  this option 
  331.                     without doing any 
  332.                     actions.
  333.  
  334.  
  335.  
  336.  
  337.  
  338.  RAW_ICMP/RAW_IP 
  339.  
  340. Service providers may support SOCK_RAW type of the socket. 
  341. There are two types of  such sockets: the first one assumes 
  342. known protocol type as written in IP header, the second one 
  343. allows to use any protocol number. The example of the first 
  344. type of socket is ICMP, the example of the second type is an 
  345. experimental protocol. The second type of protocols  also 
  346. allows an application to implement a protocol which is not 
  347. supported by service provider.
  348.  
  349. The following updates are required to support SOCK_RAW type 
  350. of  sockets:
  351.  
  352. - WSAEnumProtocol() - ipProtocol field may be set to 0. 
  353. This indicates that a caller may specify any value for 
  354. the protocol parameter to the socket() API. If 
  355. ipProtocol is set to 0, the bMultiple should be set to 
  356. true.
  357.  
  358. - It should  be stated that  when  the SOCK_RAW type of 
  359. sockets for AF_INET family  is used, it is assumed that
  360.  
  361. - when send() is called, the caller may or may not 
  362. include IP header into the buffer passed to the 
  363. send() depending on the  IP_HDRINCL option.
  364.  
  365. - when receive() is called, the caller receives 
  366. datagram which includes IP header regardless of 
  367. the IP_HDRINCL option.
  368.  
  369. - received packets are copied into  all raw socket 
  370. that which satisfy  the following conditions:
  371.  
  372. - if the protocol number is specified for the 
  373. socket, it should match the protocol number 
  374. in the IP header of the received packet;
  375.  
  376. - if a local address is defined for the 
  377. socket, it should correspond to the 
  378. destination address as specified in IP header 
  379. of the received packet;
  380.  
  381. - if a foreign address is defined for the 
  382. socket, it should correspond to the source 
  383. address as specified in IP header of the 
  384. received packet;
  385.  
  386. QUESTIONS TO DISCUSS
  387.  
  388. 1. Should we specify the required set of  supported IP 
  389. options ?
  390.